Adversarial Tradecraft in Cybersecurity by Dan Borges

Author:Dan Borges
Language: eng
Format: epub
Tags: COM060040 - COMPUTERS / Security / Online Safety & Privacy, COM043050 - COMPUTERS / Security / Networking, COM015000 - COMPUTERS / Security / Viruses & Malware
Publisher: Packt
Published: 2021-06-07T07:27:13+00:00

Executable file infection

As we briefly glimpsed in the last chapter, all three operating systems (Windows, Linux, and macOS) have a specific executable file format and a system-specific loader that moves this code into memory when the binary file is executed. On all operating systems, this function is known as the loader. The loader is responsible for parsing the executable's header then mapping corresponding sections of the executable and its libraries into memory, and finally passing execution to the newly mapped program. On Windows, these executable files are known as PEs, or Portable Executable files, often referred to by their extension as EXEs. The Windows PE is a well-documented file format that includes a rich PE header structure followed by a table with pointers to each of the PE file's various sections. The sections of a PE are also well-known structures such as executable code (.text), info data (.data, .rdata, .bss), resources (.rsrc), exported functions (.edata), imported functions (.idata), and debug info (.debug).

There is an older computer security technique known as executable file infection that involves modifying an executable file such that you can hijack its execution at run-time. This is done such that when the original executable runs, it will covertly perform your chosen action as well. The hacking group SymbolCrash, which I am proud to be a part of, published a series of libraries and tools to abuse this functionality, known as Binject. The binjection project specifically targets all three major operating systems and includes multiple methods for execution hijacking[10]. This tool originally served as a rewrite of an older project that performed this same functionality, the Back Door Factory (BDF)[11].

We will be looking at a remarkably simple execution hijacking technique on Windows, known as AddSection. With this technique, the new code is simply added as a new section to the PE and the original entry point in the PE header is changed to point to this new section. We can see this technique in action in binjection in the inject_pe.go file, specifically around line 73 (https://github.com/Binject/binjection/blob/da1a50d7013df5067692bc06b50e7dca0b0b428d/bj/inject_pe.go#L73). We can also see in that code that one telltale sign binjection is at work is the new section will have a randomly named five-character string. Understanding these IOCs left by common attacker tools is a trend we will revisit in Chapter 7, The Research Advantage. That said, this tool will be useful for us as we can now infect a known system binary and unless the defense looks closely enough, it will appear as a legitimate file.

Fortunately for us, Sliver has implemented the binjection library into their post-exploitation framework. This is nice for us as attackers as it allows us to continue using a single framework for operations instead of having to chain together many individual tools. The actual implementation of binjection is incredibly simple, only requiring a basic config and a single API call, bj.Binject(fileData, shellcode, bjConfig), as we can see in the Sliver file rpc-backdoor.go on line 74 (https://github.com/BishopFox/sliver/blob/e5a0edb72521e0aa7eb678739a158665dff2120b/server/rpc/rpc-backdoor.go#L74). One downside to using Sliver is it will generate its own shellcode for this backdoor function, using the generate.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.